Recent commit fix the test cases related to V2 api. For now, it's just a workaround and I'll discuss with Jason to come up with a better solution. Earlier we were setting all the headers null, however the change in library does not provide one universal method removeHeader but separate methods to deal with all the headers.

Not valid anymore:

response.setHeader(name, null)

Changed to:

response.getHeaderNames().stream()
            .filter(name -> !name.equalsIgnoreCase("Content-Length"))
            .forEach(name -> response.setHeader(name, ""));
        response.setContentLength(-1);

Next, there is one issue with the InstrumentedHandler which is used to track metrics for JettyHandlers. However, with the upgrade that class is not valid anymore. Though dropwizard/metrics have newer version available for Jetty12 but that is only for EE10 (InstrumentedEE10Handler), nothing for EE8 AFAIK.

In my opinion, Jetty12 + EE8 is the best next step.

does it matter that this is ee10 vs ee8 like the description?

https://issues.apache.org/jira/browse/SOLR-17503 (also linked from the ticket referenced above ticket). I don't have anything against continued support for javax per se, but there are definitely folks I've worked with that would benefit from being able to eliminate javax classes from their stack. Specifically they got tripped up by the appearance of jakarta based jetty versions (upgraded from other dependencies), which were then providing jakarta HttpServletRequests to tests based on our cloud solr test classes... boom. The goal with 17503 is to enable folks that integrate with our core code to use jakarta based servlet classes without explosion. If we do additional work to also continue to handle javax that's not a problem so long as Solr stops being the reason people can't upgrade their dependencies that also pull in jetty (or other jakarta based classes). One thing that's already sticky about our situation is our rest api stuff is already on jakarta packages ('jakarta.ws.rs:jakarta.ws.rs-api').

So IIUC, EE10 is simple to satisfy SOLR-17503 too, if we do more ok, but how important is that? is it worth the effort? I have a suspicion that we would involve separate artifacts and/or significant config gymnastics.

I picked changes from #2835 i.e. Hadoop-auth module being removed and this one and pushed a new branch to my fork.

Branch contains code for Jetty 12 + EE10 (Jakarta servlet api) https://github.com/iamsanjay/solr/tree/jetty12_ee10

I started working on ee8 because hadoop-auth module does not have any jakarta api support, however If #2835 will be merged then I believe we can transitioned to ee10 without any issue.

I picked changes from #2835 i.e. Hadoop-auth module being removed and this one and pushed a new branch to my fork.

Branch contains code for Jetty 12 + EE10 (Jakarta servlet api) https://github.com/iamsanjay/solr/tree/jetty12_ee10

I started working on ee8 because hadoop-auth module does not have any jakarta api support, however If #2835 will be merged then I believe we can transitioned to ee10 without any issue.

I've been sitting on merging the code, for no really good reason.. Thanks for highlighting that it's a bit of a blocker to your progress, I will update the PR and merge it today.

I picked changes from #2835 i.e. Hadoop-auth module being removed and this one and pushed a new branch to my fork.
Branch contains code for Jetty 12 + EE10 (Jakarta servlet api) https://github.com/iamsanjay/solr/tree/jetty12_ee10
I started working on ee8 because hadoop-auth module does not have any jakarta api support, however If #2835 will be merged then I believe we can transitioned to ee10 without any issue.

I've been sitting on merging the code, for no really good reason.. Thanks for highlighting that it's a bit of a blocker to your progress, I will update the PR and merge it today.

Merge is done!

c3c2f1c removed hadoop-auth
f7d900b is where the branch is upgraded to EE10, all the usage of javax.servlet has been replaced with jakarta.servlet

With this, changing the title of this PR as well.